Computer systems are known that utilize a firmware program stored in non-volatile memory to assist with the start up of the computer system and to enable communication with low-level hardware. For instance, personal computer systems utilize a basic input/output system (BIOS) or an extensible firmware interface (EFI) firmware that includes program code containing fundamental routines that help transfer information between elements within the computer. One of the main purposes of firmware is to bootstrap the computer system and achieve a basic boot policy that may include, but is not limited to, booting of an operating system. Firmware code may, at startup for example, be responsible for loading various blocks of code and data into the memory of a computer. Code and data may include computer instructions and data for use at the time of startup or waking (boot time) as well as instructions and data which may be accessed by running applications once control has been passed to the operating system (run time).
The strategic loading and placement of code and data into memory may be described as memory management. Existing firmware loads code and data into memory without regard to whether the code or data may only be needed during boot time. Memory is allocated sequentially or utilizing some other basis without regard to the lifespan of the code or data. Subsequently, when memory locations storing code and data needed only at boot time are freed for use by the operating system, the regions of freed memory may not be contiguous, creating gaps interspersed between run time code and data which is still in use. Such non-contiguous regions may be difficult to reuse due to their smaller size.
Moreover, creating multiple non-contiguous regions that are still in use may lead to unnecessary complexity when retrieving a memory map from a firmware. For example, in a personal computer, when the firmware hands control to an operating system during boot, the operating system may make a chain of firmware calls in order to retrieve a collection of memory map entries describing available memory blocks. Each successive firmware call may retrieve information about a different block of memory. Some operating systems may be limited to a maximum number of memory map calls, possibly preventing the retrieval of information about all blocks in memory. As such, creating multiple non-contiguous blocks of run time code and data may cause the number of calls needed to recreate a full memory map to exceed the maximum number.
It is with respect to these considerations and others that embodiments of the present invention have been made.